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(57) Abstract: The invention relates to an AAA (Authentication, Authorization, Accounting) server system (RADSS) for managing 
a pool (A) of logical addresses (IPl, IPN) and a method for updating status information within the AAA server system (RADSS). 
Said AAA server system (RADSS) comprises several AAA servers (RADl, RAD2, RAD3)- Each of the AAA servers (RADl, 
RAD2, RAD3) are assigned one or more discrete partial amounts (A 1 , A2, A3) of the address pool (A). Status information exchanged 
relating to address allocation affect the discrete partial amounts (Al, A2, A3) of addresses. The invention has the advantage of 
a low-complexity and efficient message exchange between the AAA servers (RADl, RAD2, RAD3). An efficient allocation of 
resources to logical addresses is guaranteed as a result of changes to the assignment of partial amounts (Al, A2, A3) of logical 
addresses (IPl, IPN) in AAA servers (RADl, RAD2, RAD3), according to need. 

[Fortsetzung auf der n&chsten SeiteJ 
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(57) Zusammenfassung: Die Erfindung betrifft ein AAA (Authentication, Authorization, Accounting) Serversystem (RADSS) zur 
Verwaltung eines Pools (A) von logischen Adressen (IPl. IPN) und ein Verfahren zur Aktualisierung von Statusinformationen 
innerfialb des AAA Serversystems (RADSS). Das erfindungsgemSBe AAA Serversystem (RADSS) umfasst eine Mehrzahl von AAA 
Servem (RADl, RAD2, RAD3). Jedem der AAA Server (RADl, RAD2, RAD3) sind eine oder mehrcre disjunkte Teilmengen (Al, 
A2, A3) des Adiesspools (A) zugeordnet. Ausgetauschte Statusinformationen bezuglich Adressvergabe betreffen die disjunkten 
Teilmengen (A 1 , A2, A3) von Adressen. Die Erfindung hat den Vorteil eines aufwandsarmen und effizienten Nachrichtenaustausches 
zwischen den AAA Servem (RADl, RAD2, RAD3). Eine eflfiziente Allokation der Ressourcen an logischen Adressen wild durch 
bedarfsabhangige Andeningen derZuweisung von Teilmengen (Al, A2, A3) von logischen Adressen (IPl, .... IPN) an AAA Server 
(RADl, RAD2, RAD3) gewahrleistet. 
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Beschreibung 

RRA Serversystem zur effizienten Zugangskontrolle und Adress- 
zuordnung 

5 

Die Erfindung betrifft ein AAA (Authentif ication Authorizati- 
on Accounting) Serversystem und ein Verfahren zur Verwaltung 
eines Pools von logischen Adressen. 

10 Die logische Adressierung von Teilnehmern bzw. Hosts und die 
Verwaltung des zur Verfiigung stehenden Adressraums bei Netz- 
verbunden und im Internet ist ein wichtiges Aufgabenfeld der 
Netzwerktechnik. Die notwendige Hardware ftlr die Verwaltung 
von logischen Adressen und zur Bereitstellung der entspre- 

15 chenden FunktionalitSt bei der Adressvergabe ist hSufig in 

Form von AAA (Authentif ication Authorization Accounting) Ser- 
vern bzw. AAA Server systemen gegeben, Ftir die Adress verwal- 
tung durch Multiserversysteiae mtissen Informationen Uber die 
Adressvergabe, uber zur Verfticfung stehende Ressourcen sowie 

20 Statusinformationen auf zuverlassige Weise mit einer hohen 

Ubertragungsrate zwischen den einzelnen Servern ausgetauscht 
werden • 

Bei der Einwahl von Teilnehmern in das Internet, z.B. mittels 
25 herkommlicher schmalbandiger Telef onverbindungen oder xDSL- 

Technologie (DSL: Digital Subscriber Line), kontrollieren iib- 
licherweise AAA Server den Zugang ziom Internet, die das - 
RADIUS (Remote Authentif ication Dial-In User Service) Proto- 
koll verwenden und deshalb RADIUS Server genannt werden. 
30 Hierbei findet der Obergang vom Telefonnetz zum Internet bzw. 
IP-Netz an einem Zugangsserver statt, der far das Internet 
als Network Access Server (NAS) bezeichnet wird. Bevor fiir 
einen Teilnehmer eine Verbindung aufgebaut wird, werden zwi- 
schen dem NAS und dem RADIUS Server mittels des RADIUS Proto- 
35 kolls Nachrichten ausgetauscht, um die Identitat des Teilneh- 
mers und seine Zugangsrechte im RADIUS Server Uberprtifen zu 
lassen. Ist die Antwort des RADIUS Servers positiv, d.h. der 
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Teilnehmer ist autorisiert, baut der NAS eine Verbindxang zwi- 
schen IP-Net z und dem Teilnehmer bzw. seinem Internet- 
Endgerat auf . Dabei benotigt das Internet-Endgerat des Teil- 
nehmers eine eindeutige routbare IP-Adresse. Da der Vorrat 
5 der zur Verfiigung stehenden IP-Adressen beschrankt ist, ver- 
geben die meisten Internetdienste-Anbieter - im Folgenden als 
Internet Service Provider (ISP) bezeichnet - IP~Adressen nur 
ftir die Dauer einer Internetverbindung an ihren Kunden, d.h. 
den Teilnehmer. Bei verschiedenen Internet-Sit zungen bekommt 

10 daher der Teilnehmer bzw. sein Internet-Endgerat in der Kegel 
verschiedene Internet-Adressen zugewiesen. Dem Internet Ser- 
vice Provider steht liblicherweise ein IP-Adressbereich - im 
folgenden als Adres spool bezeichnet - zur Verfiigung, aus dem 
die Adressen ftir die temporare Zuweisung an Teilnehmern ent- 

15 nommen werden* Ein Internet Service Provider kann auch tiber 
mehrere Adresspools verftlgen, beispielsweise urn mehrere Ser- 
vicegruppen ftir verschiedene Dienste bilden zu konnen. 

Die dynamische Zuordnung von IP-Adressen erfolgt tlblicherwei- 

20 se entweder im Zugangsserver bzw. NAS oder im AAA Server bzw. 
RADIUS Server. Die Zuordnung von IP-Adressen in den Zugangs- 
servern bzw. NAS hat den Nachteil eines betracht lichen Ver- 
waltungs- und Wartungsaufwandes bei Internet Service Provi- 
dern, die eine groiJe Zahl von Zugangsservern betreiben. Ad- 

25 resspools mtissen in jedem einzelnen Zugangsserver eingerich- . 
tet werden. Bei groflen Internet Service Providern ist die An- 
zahl der zu versorgenden Zugangsservern betrachtlich und 
folglich der Aufwand bei Einrichtung und Anderung von Adress- 
pools erheblich. Zudem fehlt eine zentrale Kontrolle der lau- 

30 fenden Internetverbindungen und der dabei benutzten IP- 
Adressen. Beispielsweise ftir Betreiber von Zugangsnetzwerken 
(Access Networks), die den Zugang an kleinere Internet Servi- 
ce Provider weitervermieten, ist eine zentrale Verwaltung und 
Vergabe der zur Verftigung stehenden Adresspools von groBer 

35 Wichtigkeit. 
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Bei grofien Internet Service Providern ist deshalb tiblich, 
dass die Res sour cenverwaltung und damit auch die Verwaltung 
der IP-Adressen zentral durch einen oder mehrere hochleis- 
tungsfahige und hochverfugbare AAA Server erfolgt- Unter 
5 ,,hochleistungsfahig^ ist in diesem Zusammenhang die Fahigkeit 
gemeint, eine groBe Zahl an Zugangskontrollen pro Sekunde be- 
arbeiten zu konnen. 

Eine Obliche Realisierung ftir eine hochleistungsf ahige zent- 
10 rale Steuerung ist mittels eines Multiserversystems . Dieses 
besteht in der Kegel aus einer Anzahl von Einzelrechnern bzw, 
Servern, die mittels des IP-Netzwerkes miteinander verbunden 
sind. Diese Losiing ist aufwandsanu/ weil teure ausf allssiche- 
re Hardware oder Cluster software nicht erf order lich sind. Zu~ 
15 dem ist das System durch die Hinzunahme weiterer Rechner 

leicht nach oben skalierbar. Aus Redundanzgriinden zur Aus- 
f allssicherheit sollten die Einzelrechner in der Lage sein, 
Aufgaben anderer Rechner des Multiserversystems zu uberneh- 
men, Di^ Lastverteilung auf die verschiedenen Einzelrechner 
20 des Multiserversystems erfolgt beispielsweise durch die 
RADIUS Clients auf den Zugangs servern. 

Fiir eine Verwaltung der IP-Adressen durch ein Multiserversys- 
tem miissen Inf ormationen liber die Vergabe von Adressen den 

25 Bedarf an Adressen und Zustandsinf ormationen liber laufende 
und abgeschlossene Internetsitzungen gesammelt und den Ein- 
zelrechnern verfugbar gemacht werden. Wegen der Redundanzan- 
forderungen sollten die einem Einzelrechner zur Verftlgung 
stehenden Informationen auch wenigstens einem anderen Einzel- 

30 rechner zugSngig sein. Weiter ist daftir zu sorgen, dass Ad- 
ressen durch verschiedene Einzelrechner nicht mehrfach verge- 
ben werden. 

Diese Anforderungen bei der Verwaltung von IP-Adressen durch 
35 eine Multiserversystem kSnnen beispielsweise dadurch erftillt 
werden, dass die Einzelrechner des Multiserversystems durch 
einen zentralen Server, z.B. ein DHCP (Dynamic Host Configu- 
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ration Protocol) Server oder einen unter Verwendung von her- 
stellerspezif ischen Protokollen arbeitenden Server^ mit IP- 
Adressen versorgt warden. Diese LQsung hat folgende Nachtei- 
le: 

• Der Schutz des zentralen Servers gegen Ausfalle, z.B. 
durch Doppelung, ist in der Kegel mit betrSchtlichen Auf- 
wand verbunden, 

• Fur eine zuverlassige Koitimunikation zwischen dem zentralen 
Server und den anderen Rechnern des Multiserversystems 
sollten ausgetauschte Nachrichten quittiert werden. Da- 
durch wachst die zu bearbeitende Informationsmenge mit der 
Anzahl der Rechner stark an. Die Skalierbarkeit, d.h. die 
Integration weitere Rechner in das Multiserversystem wird 
dadurch beeintrSchtigt . 

• Eine erhShte Anzahl von Verbindungswtinschen fuhrt zu einer 
Zunahme des Datenverkehrs zwischen dem zentralen Server 
und den Einzelrechnern. Daher kann es zu Belastungsspitzen 
(Bursts) kommen, die Verzogerungen bei der Bearbeitung 
verursachen konne. 

• Der zentrale Server ftihrt haufig zu zusatzlichen Wartungs- 
aufwand. 

Zur Erhohung der Ausf allsicherheit gibt es die Moglichkeit 
mittels eines erweiterten RADIUS Protokolls Zustandsinf orma- 
tionen direkt in den Zugangsservern bzw. NAS zu speichern. 
Diese Losung ist in dem RFC (Request for Comments) 2882 doku- 
mentiert, funktioniert aber nur fiir Zugangsserver die die 
entsprechende Protokollerweiterung unter sttitzen. 

Alternativ kOnnen die gesamten Inf ormationen tiber Adresspools 
auf alien Einzelrechnern des Multiserversystems gespeichert 
und Nachrichten zur Koordinierung der Adressreservierungen 
zwischen den Einzelrechnern ausgetauscht werden. Diese Vorge- 
hensweise ftihrt zu einer erheblichen Volumen an auszutau- 
schenden Nachrichten, wenn Doppelvergaben von Adressen ver- 
mieden werden sollten. 
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Die Erfindung hat zur Aufgabe, die effiziente Verwaltung von 
einem oder mehreren Adressbereichen in einem AAA-Serversystem 
anzugeben, die die Nachteile herkommlicher Methoden vermei- 
det . 

Die Aufgabe wird durch eine AAA Serversystem nach Anspruch 1 
und ein Verfahren nach Anspruch 10 gelost. 

Das Erf indungsgemaBe AAA Serversystem umfasst eine Mehrzahl 
von AAA Servern zu Verwaltung wenigstens eines Pools von lo- 
gischen Adressen. Dabei sind mehrere disjunkte Teilmengen 
bzw. Subpools wenigstens eines Adresspools jeweils genau ei- 
nem AAA Server zugeordnet. Die logischen Adressen der Teil- 
mengen des Adresspools sind jeweils nur durch den zugehorigen 
AAA Server einem Endgerat bzw. Teilnehmer zuweisbar und wer- 
den von dem zugehorigen AAA Server verwaltet (Anspruch 1) . Es 
konnen auch mehrere Teilmengen eines Adresspools einem AAA 
Server zugeordnet sein. Bei den Adresspools kann es sich bei- 
spielsweise um IP Adressbereiche handeln (Anspruch 2) . Die 
Zuweisung von Adressen zu Endgeraten durch die AAA Server des 
AAA Serversystems kann beispielsweise mit Hilfe des RADIUS 
(Remote Authentication Dial-In User Service) Protokolls oder 
des DIAMETER Protokolls erfolgen (Anspruch 3) . Diese Proto- 
kolle werden haufig zur Kommunikation zwischen einem AAA Ser- 
versystem und einem Zugangsserver oder NAS verwendet, mit 
dessen Hilfe Endgerate mit dem Netz (z.B^ Internet) verbind- 
bar sind. Die AAA Server des AAA Serversystems konnen bei- 
spielsweise mittels des Internetprotokolls bzw. TCP/IP 
(Transmission Control Protocol/Internet Protocol) miteinander 
kommunizieren (Anspruch 4 und 8) . Fur Anderungen der Zuord- 
nung von Teilmengen von logischen Adressen bzw. Subpools von 
logischen Adressen zu AAA Servern ist sinnvoll, wenn alle AAA 
Server des Serversystems tiber den gesamten Pool bzw, die ge- 
samten Pools von logischen Adressen verfUgen (Anspruch 5) . 
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Die Unterteilung von dem zur VerfUgung stehenden Adressraum 
in Teilmengen und die Zuordnung dieser Teilmengen zu AAA Ser- 
ver erlaubt den Aufwand bei der Kommunikation zwischen den 
einzelnen Servern bzw. Rechnern zu reduzieren. 

Bei dem erf indungsgemafien Verfahren zu Aktualisierung von In- 
formationen in einem erf indungsgemafien AAA Serversystem wird 
von einem ersten AAA Server des Serversystem regelmSBig eine 
Aktualisierungsnachricht an alle anderen Server des AAA Ser- 
versystems gesendet. Diese Aktualisierungsnachricht umfasst 
Informationen uber Statusanderungen bei dem ersten AAA Server 
zugeordneten Teilmengen des Adresspools bzw. der Adresspools 
seit der vorhanden gegangenen Aktualisierung • Durch das re- 
gelmafiige, beispielsweise in festen Zeitintervallen vorgenom- 
mene Senden von Aktualisierungsnachrichten der AAA Server an 
alle anderen AAA Server des AAA Serversystems kann die Verga- 
be von logischen Adressen durch die einzelnen AAA Server des 
AAA Serversystems koordiniert werden. Die sich in Gebrauch 
befindlichen Teilmengen des Adresspools bzw. der Adresspools 
kannen so an alle AAA Server signalisiert werden. Zudem kann 
eine Information bezUglich der wahrend des nachsten Zeitin- 
tervalls benotigten Ressourcen an logischen Adressen zwischen 
den Servern AAA ausgetauscht werden. Dabei schatzt ein AAA 
Server vor dem Senden der Aktualisierungsnachricht die Anzahl 
der in Zeitraum zwischen der zusendenden Aktualisierungsnach- 
richt und der darauf f olgenden Aktualisierungsnachricht zu 
vergebenden logischen Adressen ab. Dies kann geschehen, indem 
das Produkt der maximal durch den AAA Server bearbeitbaren 
Rate an Anf orderungen fur die Vergabe einer logischen Adresse 
und der dem Zeitraum zwischen der zu sendenden Aktualisie- 
rungsnachricht und der darauf folgenden Aktualisierungsnach- 
richt gebildet wird (Anspruch 12) . Die so erhaltene Abschat- 
zung liefert eine obere Grenze ftir die Anzahl der benotigten 
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Adressen. Aus den dem Server zugeordneten Teilmengen des Ad- 
resspools werden welche flir die Entnahme der nach der Ab- 
schatzung in der Zeitraum benotigten logischen Adressen be- 
stimmt. Die Aktualisierungsnachricht kann dann Inf ormationen 
5 dartiber enthalten, welche dem AAA Server zugeordneten Teil- 
mengen der Adres spools filr die Entnahme der nach der Abschat- 
zung in dem Zeitraiom benotigten logischen Adressen bestimmt 
wurden (Anspruch 11) . Auf diese Weise kSnnen Teilmengen von 
logischen Adressen als "unsicher" markiert werden, d.h. dass 

10 eine Vergabe von logischen Adressen aus diesen Teilmengen in- 
nerhalb des nachsten Zeitintervalls moglich ist. Diese Mar- 
kierung spielt eine Rolle, wenn einzelne AAA Server zusatzli- 
che Teilmengen des Adresspools benotigen, urn die Verbindungs- 
anfragen zu befriedigen. In ein solchen Fall kann die Zustan- 

15 digkeit bzw. Zuordnung von nicht als "unsicher" markierten 
Teilmengen des Adresspools geandert und dem AAA Server mit 
Mangel an logischen Adressen zugeordnet werden (Anspruch 13) . 
Bei diesem Verfahren kommunizieren die einzelnen AAA Server 
eine Mischung aus redundanten Daten und Sperrinf ormationen 

20 (markierte Teilmengen des Adresspools, deren Zuordnung nicht 
zur Disposition steht) . Dadurch wird das Volumen der Daten, 
die zwischen den Servern ausgetauscht werden, beschrankt. Den 
einzelnen AAA Servern bleibt in Regelfall verborgen, welche 
Einzeladressen von anderen AAA Servern vergeben werden. 

25 Stattdessen werden die Teilmengen kommuniziert, aus denen Ad- 
ressen vergeben werden. Die auf den einzelnen Rechnern zu 
speichernden Statusinf ormationen ist dadurch reduziert - be- 
zuglich anderer AAA Server wird der Status von (evtl, indi- 
zierten) Teilmengen statt der einzelner Adressen festgehalten 

30 - und die Datenrate des Inf ormationsaustausches zwischen den 
einzelnen Servern wird reduziert. 
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Bei Ausfall eines AAA Servers konnen die diesem AAA Server 
zugeordneten Teilmengen des Adresspools einem anderen AAA 
Server, z.B. nach MalJgabe einer Prioritatsliste, zugeordnet 
werden (Anspruch 14 und 15). Evtl. werden die Teilmengen des 
ausgefallenen Servers auch zwischen mehreren anderen AAA Ser- 
vern verteilt. Es ist dann sinnvoll, Teilmengen von logischen 
Adressen, die bei der letzten erhaltenen Aktualisierungsnach- 
richt des ausgefallenen Server als ,,unsicher" markiert war- 
den, far eine Zeitspanne nicht ftir die Neuvergabe von logi- 
schen Adressen zu nutzen (Anspruch 16) . Diese Zeitspanne kann 
beispielsweise der maximale erlaubten Verbindungsdauer ent- 
sprechen (Anspruch 17) . Aktualisierungsnachrichten konnen 
auch beim Neubooten von AAA Servern des AAA Serversystems 
verwendet werden. Beispielsweise tlbermittelt ein neugeboote- 
ter AAA Server an die anderen AAA Server eine Multicastnach- 
richt, mit der er die Obersendung von Aktualisierungsnach- 
richten und die Zuordnung von Teilmengen des Adresspools an- 
fordert (Anspruch 18). Als Transportprotokoll zu Vermittlung 
von Aktualisierungsnachrichten kOnnen das TCP/IP Protokoll, 
das RADIUS Protokoll oder DIAMETER Protokoll verwendet wer- 
den. Durch das reduzierte Volumen an ausgetauschten Nachrich- 
ten ist es moglich, dass die einzelnen Server des Serversys- 
tems an verschiedenen Orten d.h. dezentral aufgestellt werden 
{Anspruch 9) . 



Weitere vorteilhafte Weiterbindungen des Erf indungsgegenstan- 
des sind in den weiteren Unteranspruchen angegeben. 

Im folgenden wird die Erfindung im Rahmen eines Ausftihrungs- 
beispiels anhand von ftinf Figuren naher erlautert. Es zeigen: 



Fig. 1: Ein Szenarium ftir die dynamische Zuordnung von Adres- 
sen ftir Internetsitzungen. 
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Fig. 2: Die Aufteilung eines Adressbereiches bzw. Adresspools 
in Teilmengen bzw. Subpools. 

5 Fig. 3: Die Zuordnung von Teilmengen an logischen Adressen zu 
RADIUS Servern. 

Fig. 4: Den Austausch von Aktualisierungsnachrichten zwischen 
drei RADIUS Servern. 

10 

Fig. 5: Die verschiedenen Schritte bei der Anforderung einer 
zusatzlichen Teilmengen an logischen Adressen. 

Im Rahmen des Ausftihrungsbeispiels wird angenommen, dass ein 
15 Oder mehrere IP Adressbereiche durch ein RADIUS Serversystem^ 
d.h. eine Multiserversystem^ das mittels des RADIUS Proto- 
kolls arbeitet/ verwaltet werden. Das RADIUS Serversystem be- 
steht aus mehreren RADIUS Servern, die mit Hilfe eines Netz- 
werkes verbunden sind. Spezielle Software, z.B. Clustersoft- 
20 ware, wird nicht benotigt. Der Einfachheit halber wird ange- 
nommen, dass im Rahmen des Ausftihrungsbeispiels ein Adress- 
pool einem IP Adressbereich und Teilmengen des Adresspools 
Teilbereichen von IP Adressen entsprechen. Ein globaler Ad- 
ressbereich bzw. Adresspool kann einem Internet Service Pro- 
25 vider zugeordnet sein oder fUr bestimmte Dienstklasse reser- 
viert werden. 

Im Figur 1 sind Internetendgerate Hostl, Host5 darge- 

stellt, tiber die Teilnehmer eine Verbindung zum Internet INT 
30 aufbauen konnen. Mit Hilfe des IP (Internet Protokolls) Pro- 
tokolls IP, das Uber dem PPP (Point- to-Point Protocol) Proto- 
kpll PPP lauft, kann eine Verbindung zwischen dem Endgerat 
Hostl . . . Host5 und einem Zugangsserver NAS hergestellt wer- 
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den. Bevor von dem Zugangsserver eine Verbindiong mit dem In- 
ternet INT hergestellt wird, wird eine Anfrage bei dem RADIUS 
Serversystem RADSS durchgefOhrt . Der Austausch von Nachrich- 
ten zwischen dem Zugangsserver NAS und dem RADIUS Serversys- 
5 tem RADSS erfolgt mit Hilfe des Radiuspro toko lis RADIUS. Das 
RADIUS Serversystems RADSS verfUgt Ober einen Pool IPPool von 

eigenen IP Adressen @IP1/ ^ @Ipn , die dynamisch fiir den 

Zeitraum der Verbindung den Internetendgeraten Hostl, -../ 
Hostn zugeordnet werden. Nach Erhalt der Autorisierungsnach- 
10 richt durch das RADIUS Serversystem und der Zuteilung einer 
IP Adresse ftir den Zeitraum der Verbindung baut der Zugangs- 
server NAS eine Internetverbindung ftir das anfragende Inter- 
netendgerat Hostl, Hosts auf. 

15 In Figur 2 ist ein Adresspool A dargestellt, der aus dem Ad- 
ressbereich IP 1 bis IP N besteht. Dieser Adresspool A wird 
in drei Teilmengen Al^ A3 unterteilt, die den Teiladress- 

bereichen IP 1 bis IP I, IP J bis IP und IP L bis IP N 
entsprechen. Jeder der RADIUS Server verftlgt tlber den gesam- 

20 ten Adresspool A, d.h. auf alien Servern ist der gesamte Ad- 
ressbereich gespeichert . Jeder der RADIUS Server kann IP Ad- 
ressen jeder beliebigen Teilmengen Al, A3 von IP Adres- 
sen freigeben. Dagegen besteht ein exklusives Recht der Zu- 
ordnung von IP Adressen ftir Verbindungen^ d.h. jeder RADIUS 

25 Server hat eine oder mehrere Teilmengen Al^ A3 von Adres- 

sen zugeordnet, aus der er IP Adressen vergeben kann. Diese 
Vergaberechte von IP Adressen konnen dynamisch zwischen den 
RADIUS Servern verschoben werden. In Figur 3 sind drei RADIUS 
Server RADl, RAD3 dargestellt. Jedem ist ein Teilbereich 

30 von Adressen Al, A3 zugewiesen (durch durchgezogene 

Pfeile gekennzeichnet) , aus den er Adressen zuordnen kann. 
Alle drei RADIUS Server konnen beniitzte Adressen freigeben, 
was durch durchbrochene Pfeile gekennzeichnet ist. 
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In Figiir 4 ist gezeigt, wie bei den einzelnen RADIUS Servern 
die Aktualisierung von Informationen iiber den Status der an- 
dere RADIUS Server vorgenommen wird. In regeliaSfiigen Zeitab- 
5 standen sendet jeder RADIUS Server RADl, RAD3 eine Aktu- 

alisierungsnachricht an alle andern RADIUS Server RADl, 
RAD3, xxra tiber Anderungen bezuglich der zugeordneten Teilmen- 
gen an Adressen zu Inforiaieren. Diese Aktualisierungsnach- 
richt wird mit Hilfe von einem IP Multicastmechanismus ver- 

10 sendet und betrifft nur Teilmengen, hinsichtlich der sich 

seit der letzten Aktualisierungsnachricht eine Anderung erge- 
ben hat- Aktualisierungsnachrichten warden nicht quittiert. 
Die Doppeltvergabe von IP Adressen ist ausgeschlossen, weil 
schliimnstenf alls eine Freigabeinf ormation verloren geht, d.h. 

15 eine Information, die eine bereits benutzte IP Adresse be- 
trifft. Die Freigabe erfolgt dann spater, nachdem der Timer 
ftir die maximale Vergabezeit ausgelaufen ist. Zusatzlich ent- 
halt die Aktualisierungsnachricht Informationen iiber die 
Teilmengen von Adressen, aus welchen voraussichtlichen im 

20 folgende Zeitintervall IP Adressen vergeben werden. In Frage 
kommen dabei Teilmengen, die noch nicht vergebene IP Adressen 
zu VerfUgung haben. Entsprechend Figur 4 sendet RADIUS Server 
RADl zu den Zeitpunkten Sl.l und SI. 2 Aktualisierungsnach- 
richten UpdtRADl (fur: Update von RADl) an die RADIUS Server 

25 RAD2 und RAD3. Zu verschobenen Zeitpunkten S2 . 1 und S2.2 bzw. 
S3.1 und 33,2 senden der RADIUS Server RAD2 bzw. RADIUS Ser- 
ver RAD3 Aktualisierungsnachrichten UpdtRAD2 bzw. UpdtRAD3 
jeweils an die beiden anderen RADIUS Server RADl und RAD 3 
bzw. RADl und RAD2 . 

30 

Auf jedem der RADIUS Server RADl, RAD3 werden folgende 

Informationen gespeichert, die den gesamten bzw. globalen Ad- 
resspool A betreffen: 
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ein Bezeichner ftir den globalen Adres spool A fur den Fall, 
dass mehrere globale Adresspools, beispielsweise ftir ver- 
schiedene Dienstklassen, verwendet werden. 
Eine Liste von den RADIUS Servern RADl, RAD3, die 

Zugriff auf Adressen des globalen Adresspools A haben. 
Diese Liste beinhaltet die IP Adresse jedes RADIUS Servers 
RADl, RAD3, einen Bezeichner fur jeden RADIUS Server 

RADl, RAD3, den Zeitpunkt der letzten Aktualisierung 

ftir jeden RADIUS Server RADl, RAD3 und die Gesamtzahl 

der aktuell freien, d.h. nicht vergebenen IP Adressen. 
Die erste IP Adresse des globalen Adressbereichs A. 
Die Anzahl von IP Adressen, die zu diesem Adressbereich A 
gehoren. 

Die Zeitspanne zwischen zwei Aktualisierungen. 

Die maximale Zeitdauer, die ftir die Verbindung eines In- 

ternetendgerats vorgesehen ist. 

Die Liste der Teilmengen von IP Adressen, beispielsweise 
in Form von Pointers, die jeweils auf die erste IP Adres- 
sen des Teilbereichs zeigen. 

Optional eine Liste von Zugangs servern bzw. Portkennungen. 
Diese Liste enthait alle verbundenen NAS in Form Ihrer IP 
Adressen oder Ihrer NAS Kennungen und ihrer Portzahlen. 
Ftir einen globalen Adresspool A kann zusatzlich ein Flag 
definiert werden, dass einen Mangel an freien IP Adressen 
anzeigt. Dieses Flag wird beispielsweise gesetzt, wenn die 
Gesamtzahl der freien IP Adressen kleiner wird als ein 
Schwellenwert, beispielsweise die Zeitspanne zwischen Ak- 
tualisierungen multipliziert mit der maximalen Rate an An- 
fragen nach IP Adressen, Das Setzen des Flags wird ruck- 
gangig gemacht, wenn die Anzahl der freien Adressen wieder 
den Schwellenwert ubersteigt. 
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Folgende Infonaationen bezUglich der Teilmengen von Adressen 
werden auf alien RADIUS Servern gespeichert: 

• Der Bezeichner des RADIUS Servers, der ftir die Teilmenge 
an Adressen verantwortlich ist, d.h. der AAA Server, der 

5 aus dieser Teilmenge IP Adressen vergeben kann. 

• Die erste IP Adresse der Teilmenge bzw. des Teilbereiches 
an IP Adressen. 

• Die Anzahl der von der Teilmenge umfassten IP Adressen. 



10 Die auf den AAA RADIUS Servern vorgehaltenen, auf die Teil- 
mengen an Adressen bezogenen Informationen werden in regelmS- 
Jiigen Zeitabstanden aktualisiert . Die Aktualisierung wird 
ausgelost durch das Ablaufen eines Timers, der das Zeitinter- 
vail zwischen zwei Aktualisierungsnachrichten misst. Von dem 

15 RADIUS Server, der Aktualisierungsnachrichten hinsichtlich 
des Status seiner Teilmengen an Adressen sendet, werden die 
freien, d.h. nicht vergebenen Adressen, der zugeordneten 
Teilmengen an Adressen bestimmt und die Teilmengen, welche 
innerhalb des nachsten Zeitintervalls zur Benutzung in Frage 

20 kommen, identif iziert . Die Aktualisierungsnachricht umfasst 

dann die Kennung des Radius servers, von dem die Nachricht ge- 
sendet wird, die Gesamtzahl der freien IP-Adressen dieses 
RADIUS Servers, die Kennungen bzw. Bezeichner der Teilmengen 
an Adressen, die ftir eine Benutzung innerhalb des nSchsten 

25 Zeitintervalls in Frage kommen, d.h. die als „unsicher'* mar- 
kiert sind, Anderung hinsichtlich der Benutzung von Teilmen- 
gen seit der letzten Aktualisierungsnachricht und gegebenen- 
falls weitere Statusinformationen. Nach dem Senden der Aktua- 
lisierungsnachricht wird der Timer neu gestartet. Ein RADIUS 

30 Server, der eine Aktualisierungsnachricht erhalt, setzt einen 
Oberwachungstimer neu, der misst, wie viel Zeit seit der 
letzten Aktualisierungsnachricht verstrichen ist. Anhand der 
empfangenen Aktualisierungsnachricht bringt der RADIUS Server 
die Statusinformationen tiber den sendenden Radiusserver auf 

35 den neusten Stand. 
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In Figur 5 ist der Austausch von Nachrichten zur und wahrend 
der Verbindxing eines Teilnehmers bzw. EndgerSts dargestellt. 
Von einem NAS (Network Access Server) wird fUr die Verbindung 
eines Internetendgerates eine Authentif izierungsanf rage rAUTH 
mit Hilfe des Radiusprotokolls RADIUS an einen RADIUS Server 
RADl gerichtet. Diese Authentif izierungsanf rage rAUTH enthait 
die Kennung des NAS, den Bezeichner des Ports und die Kennung 
des Teilnehmers bzw, Endgerates. Von dem RADIUS Server RADl 
wird eine Anfrage rLDAP an eine LDAP (Lightweight Directory 
Access Protocol) -Datenbank LDAP gestellt, im Zuge derer die 
Kennung bzw. Identitat des Teilnehmers ermittelt wird. Von 
der LDAP-Datenbank LDAP wird in der Antwort aLDAP die Kennung 
der Teilmenge von Adressen mitgeteilt, aus der die IP-Adresse 
zu entnehmen ist. Daraufhin wird eine IP-Adresse aus dieser 
Teilmenge von IP-Adressen bestimmt. AnschlieBend teilt der 
RADIUS Server die bestimmte IP-Adresse dem NAS in einer Ant- 
wort aAUTH auf die Authentif izierungsanf rage mit. Die Tatsa- 
che dieser neuen Verbindung wird den anderen Radiusservern 
RAD2 im Zuge einer Aktualisierungsnachricht UpdtRADl z.B. in 
Form einer aktualisierten Gesamtzahl an benUtzten IP-Adressen 
und evtl. durch die Neumarkierung der entsprechenden Teilmen- 
ge an Adressen als ^unsicher"* mitgeteilt. Analog erhalt der 
Radiusserver RADl wahrend der Verbindung Aktualisierungsnach- 
richten UpdtRAD2 von anderen Radiusservern RAD2 . Wenn die 
Verbindung unterbrochen werden soil, sendet der NAS eine 
Nachricht astop an den RADIUS Server, mit der die Abrechnung 
bzw. das Accounting fur die entsprechende Verbindung unter- 
brochen werden soil. Diese Nachricht enthalt die Kennung des 
Teilnehmers und die zugewiesene IP-Adresse. Der RADIUS Server 
RADl quittiert diese Nachricht dem NAS, wobei die Quittie- 
rungsnachricht ACKastop wieder die Kennung des Teilnehmers 
und die verwendete IP-Adresse enthalt. Nach Beendigung der 
Verbindung werden in der darauf f olgenden Aktualisierungsnach- 
richt UpdtRADl die anderen Radiusserver RAD2 mit den entspre- 
chend aktualisierten Statusinf ormationen versorgt. 



wo 03/081875 




PCT/DE03/00895 



15 

Werm der RADIUS Server nicht iiber genug Teilmengen an Adres- 
sen far die Anfragen durch Zugangsserver bzw, NAS verftigt, 
kann er die Zuordnung weiterer Teilmengen an IP-Adressen an- 
fordern* Eine derartige Anfrage bzw. Anforderung wird ausge- 
5 15st, wenn die Gesamtzahl freier IP-Adressen des RADIUS Ser- 
vers eine Schwelle unterschreitet^ die beispielsweise durch 
das Produkt des Zeitintervalls zwischen Aktualisierungsnach- 
richten und der maximal bearbeitbaren Rate an Verbindungswun- 
schen gegeben ist. In diesem Fall setzt der RADIUS Server ein 

10 Flag, das den Mangel an IP-Adressen anzeigt. Der RADIUS Ser- 
ver tiberpruft anhand der Status informationen der anderen 
RADIUS Server, welcher Server die groBte Anzahl an freien IP- 
Adressen bzw. die groBte Anzahl an nicht markierten bzw. 
nicht benutzten Teilmengen an Adressen aufweist. Falls ein 

15 RADIUS Server identif iziert werden kann, der Uber betracht- 
lich mehr freie Adressen als den Schwellenwert fUr Mangel an 
IP-Adressen verfUgt, wird von dem RADIUS Server mit Adress- 
mangel eine Anforderung fiir Zuweisung einer weiteren Teilmen- 
ge an Adressen gesendet. Mit Senden dieser Nachricht wird ein 

20 Oberwachungstimer gesetzt. Bei einer negativen Antwort sendet 
der RADIUS Server mit Adressenmangel eine entsprechende An- 
frage an andere RADIUS Server nach MaBgabe der dort freien 
Adressen. Falls kein RADIUS Server mit freien IP-Adressen in- 
fiziert werden kann oder wenn keine Antworten von den RADIUS 

25 Servern erhalten werden, wartet der RADIUS Server mit Adress- 
mangel wenigstens ein Aktualisierungszeitintervall, bevor er 
seine Anfragen wiederholt. Falls in diesem Zeitraum alle 
freien IP-Adressen vergeben werden, werden zusatzliche Au- 
thentif izierungsanf ragen von NAS zuriickgewiesen. Wird dagegen 

30 eine positive Antwort auf die Anforderung einer neuen Teil- 
menge an Adressen erhalten, so wird diese positive Antwort 
mit einer Quittierungsnachricht an alle anderen RADIUS Server 
mittels Multicast quittiert und intern werden alle relevanten 
Daten aktualisiert . Dieser Mechanismus kann auch nach einen 

35 Reboot eines der RADIUS Server zur automatischen Rekonfigura- 
tion des RADIUS Servers verwendet werden. 
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Beim Ausfall eines der RADIUS Server wird durch sine Liste 
der Kennungen der RADIUS Server eine Hierarchie der Zustan- 
dlgkeit vorgegeben. Nachdem von dem ausgef allenen RADIUS Ser- 
ver keine Aktualisierungsnachrichten mehr erhalten werden, 
5 tibernimmt der RADIUS Server an der Spitze der Hierarchie oder 
der darauf folgende RADIUS Server die Kontrolle bzw. Verwal- 
tung der entsprechenden IP~Adressbereiche . Dabei laufen im 
RADIUS Server/ der die Verwaltung der Teiliaengen von Adressen 
uberniinmt/ folgende Schritte ab: 

10 Die Obernahme von Adressen wird durch den Ablauf des Oberwa- 
chungstimers angestoBen. Danach wird eine Anforderung fiir ei- 
ne Aktualisierungsnachricht an den ausgef allenen RADIUS Ser- 
ver gesendet. Wenn darauf hin keine Antwort enthalten wird^ 
werden mittels einer Multicast-Nachricht alle anderen RADIUS 

15 Server dartlber informiert, dass der RADIUS Server, der die 
Multicast-Nachricht sendet, die Verwaltung und Zuordnung der 
Teilmengen von Adressen des ausgef allenen RADIUS Servers ti- 
bernimmt • Die Teilmengen von Adressen des ubernehmenden 
RADIUS Servers werden urn die tlbernommenen Teilmengen von Ad- 

20 ressen erweitert- Dabei werden als /^unsicher"" markierte Teil- 
mengen blockiert und ein Timer fur die Blockierung gestartet. 
Dieser Timer misst die maximale Zeit ftir die Zuordnung einer 
IP-Adresse fur eine Verbindung. Nach Ablauf des Timers wird 
die Blockierung der Teilmengen von Adressen zurilckgenommen. 

25 Nun sind alle Ressourcen an IP-Adressen wieder verfugbar und 
der Ausfall des RADIUS Servers ist vollstandig kompensiert- 
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Patent anspruche 

1. AAA Serversystem (RADSS) , uitifassend eine Mehrzahl von AAA 
Servern (RADl, R7\D2, RAD3), zur Verwaltung eines Pools (A) 

5 von logischen Adressen (IPl^ • • .IPN) , 
dadurch gekennzeichnet / ■ 

- dass mehrere disjunkte Teilmengen (Al, A2, A3) des Adress- 
pools (A) gegeben sind, 

- dass jede der disjunkten Teilmengen (Al, A2, A3) des Ad- 

10 resspools (A) genau einem AAA Server (RADl, RAD2, RAD3) zuge- 
ordnet ist, und 

- dass die logischen Adressen der Teilmengen (Al, A2, A3) des 
Adresspools (A) nur jeweils durch den zugehSrigen AAA Server 

(RADl, RAD2, RAD3) einem EndgerSt zuweisbar sind, 

15 

2. AAA Serversystem nach Anspruch 1, 
dadurch gekennzeichnet , 

- dass die logischen Adressen (IPl/ IPN) durch IP (Internet 

Protocol) Adressen gegeben sind. 

20 

3* AAA Serversystem nach Anspruch 1 oder 2, 
dadurch gekennz eichne t , 

- dass von den AAA Servern (RADl, RAD2, RAD3) des AAA Server- 
systems (RADSS) mittels des RADIUS Protokolls oder des 

25 DIAMETER Protokolls logische Adressen fur Endgerate zuweisbar 
sind- 

4. AAA Serversystem nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, 

30 - dass zwischen den AAA Servern (RADl, RAD2, RAD3) des AAA 

Serversystems (RADSS) Nachrichten mittels des Internet Proto- 
kolls austauschbar sind. 

5. AAA Serversystem nach einem der vorhergehenden Anspruche, 
35 dadurch gekennzeichnet. 
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- dass der gesamte Pool (A) von logischen Adressen 
(IP1,...IPN) auf alien AAA Servern (RADl, RAD2, RAD3) des AAA 
Serversystems (RADSS) gespeichert ist. 

5 6. AAA Server system nach einem der vorhergehenden Ansprtiche/ 
dadurch gekennzeichne t ^ 

- dass die Zuordnung von Teilmengen (Al, A2^ A3) des Adress- 
pools (A) zu AAA Servern (RADl, RAD2, RAD3) dynamisch ander- 
bar ist. 

10 

7. AAA Serversystem nach einem der vorhergehenden Ansprtiche, 
dadurch. gekennzeichne t , 

- dass mehrere Adresspools (A) von logischen Adressen gegeben 
sind, von denen disjunkte Teilmengen (Al, A2, A3) AAA Servern 

15 (RADl, RAD2, RAD3) des AAA Serversystems (RADSS) zugeordnet 
sind, 

- dass verschiedene Dienstklassen gegeben sind, und 

- dass ftlr die Vergabe von logischen Adressen im Rahmen eines 
Dienstes einer der Dienstklassen eine Zuordnung von verschie- 

20 denen Adresspools (A) zu genau einer Dienstklasse gegeben 
ist . 

8 . AAA Serversystem nach einem der vorhergehenden Ansprtiche, 
dadurch gekennzeichnet , 
25 - dass Nachrichten zwischen den AAA Servern (RADl, RAD2, 

RAD3) des AAA Serversystems (RADSS) mittels des TCP/IP Proto- 
kolls austauschbar sind. 

9- AAA Serversystem nach einem der vorhergehenden AnsprUche, 
30 dadurch gekennzeichnet , 

- dass wenigstens zwei der AAA Server (RADl, RAD2, RAD3) des 
AAA Serversystems (RADSS) an unterschiedlichen Orten positio- 
niert sind. 

35 10. Verfahren zur Aktualisierung von Inf ormationen in einem 
AAA Serversystem nach Anspruch 1, bei dem 
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- von einem ersten AAA Server (RADl^ RAD2, RAD3) des AAA Ser- 
versys terns (RZUDSS) regelmafiig eine Aktualisierungsnachricht 
(UpdtRADl, UpdtRAD2, UpdtR7^3) an alle anderen AAA Server 
(RADl, RAD2, RAD3) des AAA Serversystems (RADSS) gesendet 

5 wird, 

- diese Aktualisierungsnachricht (UpdtRADl, UpdtRAD2^ 
UpdtRADS) Informationen tlber Statusanderungen von deia ersten 
AAA Server (RADl, RAD2, RAD3) zugeordneten Teilmengen (Al, 
A2, A3) des Adresspools (A) seit der vorangegangenen Aktuali- 

10 sierungsnachricht (UpdtRADl, UpdtRAD2, UpdtRAD3) umfasst. 

11. Verfahren nach Anspruch 10, 
dadurch gekennzeichne t , 

- dass vor dem Senden der Aktualisierungsnachricht 

15 (UpdtRADl, UpdtRAD2, UpdtRAD3) im ersten AAA Server (RADl, 

RAD2, RAD3) eine AbschStzung der im Zeitraum zwischen der zu 
sendenden Aktualisierungsnachricht (UpdtRADl, UpdtRAD2, 
UpdtRAD3) und der darauf f olgenden Aktualisierungsnachricht 
(UpdtRADl, UpdtRAD2, UpdtRADS) zu vergebenden logischen Ad- 

20 ressen durchgeftihrt wird, 

- dass dem ersten AAA Server (RADl, RAD2, RAD3) zugeordnete 
Teilmengen (Al, A2, A3) des Adresspools (A) ftir die Entnahme 
der nach der Abschatzung in dem Zeitraum benotigten logischen 
Adressen bestimmt werden, und 

25 - dass die Aktualisierungsnachricht (UpdtRADl, UpdtRAD2, 

UpdtRADS) zusatzlich Informationen dartiber enthalt, welche 
dem ersten AAA Server (RADl, RAD2, RAD3) zugeordnete Teilmen- 
gen (Al, A2, A3) des Adresspools (A) ftir die Entnahme der 
nach der Abschatzung in dem Zeitraum benotigten logischen Ad- 

30 ressen bestimmt wurden* 

12. Verfahren nach Anspruch 11, 
dadurch gekennzeichnet , 

- dass ftir die Abschatzung das Produkt der maximal durch den 
35 AAA Server (RADl, RAD2, RAD3) bearbeitbare Rate an Anforde- 

rungen ftir die Vergabe einer logischen Adresse und der dem 
Zeitraum zwischen der zu sendenden Aktualisierungsnachricht 
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(UpdtRADl, UpdtRAD2, UpdtRAD3) und der darauf folgenden Aktua- 
lisierungsnachricht (UpdtRADl, UpdtRAD2, UpdtRADS) gebildet 
wird. 

5 13. Verfahren nach einem der Anspriiche 10 bis 12, 
dadurch gekennzeichnet , 

- dass der erste AAA Server (RADl, RAD2^ RAD3) tiberpruft^ ob 
die entsprechend der Abschatzung benotigten Teilmengen (Al, 
A2, A3) des Adres spools (A) zur Verfugung stehen, und 
10 - dass bei negativen Ergebnis der Oberpriifung durch den ers- 
ten AAA Server (RADl, RAD2, RAD3) bewirkt wird, dass eine 
Teilmenge eines anderen AAA Servers (RADl, RAD2, RAD3) dem 
ersten AAA Server (RADl, RAD2, RAD3) zugeordnet wird. 

15 14. Verfahren nach einem der Anspruche 10 bis 12, 
dadurch gekennzeichne t , 

dass bei Ausfall des ersten AAA Servers (RADl, RAD2, RAD3) 
die dem ersten AAA Server (RADl, RAD2, RAD3) zugeordneten 
Teilmengen (Al, A2, A3) des Adresspools (A) einem zweiten AAA 
20 Server (RADl, RAD2, RAD3) zugeordnet werden. 

15. Verfahren nach Anspruch 14, 
dadurch gekennzeichnet , 

dass der zweite AAA Server (RADl, RAD2, RAD3) nach MaBgabe 
25 einer Prioritatsliste von AAA Servern (RADl, RAD2, RAD3) be- 
stimmt wird. 

16. Verfahren nach Anspruch 11 und einem der Anspruche 14 o- 
der 15, 

30 dadurch gekennzeichnet, 

dass die entsprechend der letzten von dem zweiten AAA Server 
(RADl, RAD2, RAD3) erhaltenen Aktualisierungsnachricht des 

ersten AAA Servers (RADl, RAD2, RAD3) ftlr die Entnahme der 

nach der Abschatzung in dem Zeitraum benStigten logischen Ad- 
35 ressen bestimmten Teilmengen (Al, A2, A3) des Adresspools (A) 

bei Ausfall des ersten AAA Servers (RADl, RAD2, RAD3) fUr ei- 
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ne Zeitspaxme nicht fUr die Neuvergabe von logischen Adressen 
(IPl, .../ IPN) genutzt wird. 

17. Verfahren nach Anspruch 16, 
dadurch gekennzeichnet , 

dass die Zeitspanne nach MaBgabe der maximal erlaubten Ver- 
blndungsdauer bestimmt wird. 

18. Verfahren nach einem der vorhergehenden AnsprUche, 
dadurch gekennz eichne t , 

- dass ein zweiter AAA Server (RADl, RAD2, RAD3) neu gebootet 
wird, und 

- dass von dem zweiten AAA Server (RADl, RAD2, RAD3) eine 
Multicast-Nachricht an alle anderen AAA Server (RADl, RAD2, 
RAD3) des AAA Serversys terns (RADSS) tibermittelt wird, wodurch 
die Ubersendung von Aktualisierungsnachrichten (UpdtRADl, 
UpdtRAD2, UpdtRADS) und die Zuordnung von Teilmengen (Al, A2, 
A3) des Adresspools (A) an den ersten AAA Server (RADl, RAD2, 
RAD3) angefordert wird. 

19. Verfahren nach einem der vorhergehenden Anspruche, 
dadurch gekennz ei chnet , 

- dass als Transportprotokoll zur Obermittlung von Aktuali- 
sierungsnachrichten (UpdtRADl, UpdtRAD2, UpdtRAD3) das TCP/IP 
Protokoll, das RADIUS Protokoll Oder das DIAMETER Protokoll 
verwendet wird. 
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